Field of the Invention
The present invention relates generally to a method and apparatus for providing broadcast services in a broadcasting system. In particular, the present invention relates to an access information transmission/reception method and apparatus for efficiently achieving access to broadcast services, and a system and terminal thereof.
Description of the Related Art
The mobile communication market continuously requires production of new services through for example, the recombination or integration of existing technologies. Today, with the development of communication and broadcast technologies, the conventional broadcasting system or mobile communication system has reached the phase of providing broadcast services through portable terminals (or mobile terminals), such as mobile phones and personal digital assistants (PDAs). Due to the latent and actual market needs and the increasing demand for multimedia services, the service providers' intended strategies for providing new services such as broadcast service in addition to the existing voice service, and the identified interests of Information Technology (IT) companies which are bolstering their mobile communication businesses to meet the user's demands, convergence of the mobile communication service and the Internet Protocol (IP) has become the mainstream of development of the next generation mobile communication technologies.
The Open Mobile Alliance (OMA), one of the standardization groups for broadcast services, was established in June, 2002, by about 200 companies including Nokia, NTT and IBM, to perform research on the standard for interworking between individual mobile solutions. The OMA mainly serves to define various application standards for mobile games and Internet services. Of the working groups belonging to the OMA, the Open Mobile Alliance Browser and Content Mobile Broadcast Sub Working Group (OMA BAC BCAST) is now performing research on the technology for providing broadcast services using mobile terminals. A brief description will now be made of the broadcasting system which is under discussion in the OMA.
In a BCAST system, which is a broadcasting system proposed by the OMA, a mobile terminal desiring to receive a broadcast service should receive so-called service guide information containing description information for the service, billing information for the service, and information on a receiving method for the service. The mobile terminal receives the service according to the information provided through the service guide information. A description will now be made of the conventional broadcast service access method with reference to the BCAST system as an example of the general broadcasting system using the service guide. FIG. 1 is a block diagram illustrating a structure of a service guide used for receiving broadcast services in a general broadcasting system. This structure is proposed to provide broadcast services to the mobile terminal in the BCAST system. One service guide is comprised of a plurality of groups each having its own purpose, and all the groups are classified into four groups according to use, as shown in FIG. 1. FIG. 1 illustrates an exemplary service guide comprised of an administrative group 100, a provisioning group 110, a core group 120, and an access group 130.
The administrative group 100 is a group for providing basic information needed by a mobile terminal to receive a service guide and includes a service guide context fragment 101 and a service guide delivery descriptor fragment 102. The service guide context fragment 101 provides a service guide identifier (ID), identification information of the service provider that generated and transmitted the service guide, and the entire information on the service guide. The service guide delivery descriptor fragment 102 provides a channel capable of receiving fragments for a plurality of service guides, scheduling information, and update information to a mobile terminal so that the mobile terminal may receive only the necessary service guide at an appropriate time.
The provisioning group 110 is a group for providing fee information for service reception and includes a purchase item fragment 111, a purchase data fragment 112, and a purchase channel fragment 113. The purchase item fragment 111 provides fee information for a service or a service bundle, the purchase data fragment 112 provides information indicating how a service user can pay the fee, and the purchase channel fragment 113 provides information on the system where the service user can actually purchase the service.
The core group 120 is a group for providing information on the service itself and includes a service fragment 121, a schedule fragment 122, and a content fragment 123. The service fragment 121 provides a description of the service itself that the user will receive, and also provides information indicating with which content the service can be configured. The schedule fragment 122 provides information on the time at which the service can be provided and used. The content fragment 123 provides information on a plurality of contents constituting the service.
The access group 130 includes an access fragment 131 and a session description fragment 132, and provides service access information indicating how to receive the services provided through the core group 120, and detailed information on the session in which the contents constituting the corresponding service are transmitted, so as to allow the mobile terminal to access the corresponding service. The access fragment 131 provides a plurality of access methods for one service to the mobile terminal, thereby providing a method capable of accessing various additional services based on one service. The session description fragment 132 provides session information for the service defined in one access fragment.
The service guide information, as shown in FIG. 1, can further include a preview data fragment 124 that provides a preview and icon for the service and content in addition to the foregoing four fragments.
With reference to Table 1 to Table 7 below, a description will now be made of the details of the access fragment defined in the conventional OMA BCAST by way of example. Table 1 to Table 7 are divided from one table, for convenience, and a definition of items in each table follows the definition of Table 1.
TABLE 1DataNameTypeCategoryCardinalityDescriptionType201AccessEO0 . . . NAccess fragmentContains the following attributes:idversionvalidFromvalidToServiceProtectionAccessTypeAudioLanguageContains the following sub-elements:ExtensionURLAccessTypeServiceIDUsageInfoSessionDescriptionURISDPInteractiveAccessURLTerminalCapabilityRequirementBandwidthRequirementApplicationSpecMediaInformation
In Table 1, a first item “Name” indicates names of attributes or elements of an access fragment, and a second item “Type” indicates whether each object included in the access fragment corresponds to Attribute (A) or Element (E). As to a difference between the attribute and the element, the attribute is a value indicating an attribute of an access fragment and its element, and the element is a value indicating the information actually used. A third item “Category” indicates whether the attribute or element is a mandatory value (M) or an optional value (O). A fourth item “Cardinality” indicates whether the attribute or element is repeated, and a fifth item “Description” indicates a description of the attribute or element. Finally, a sixth item “Data Type” indicates a data type of the attribute or element.
In Table 1, reference numeral 201 indicates what the attribute or element included in the access fragment comprises.
TABLE 2202idAM1ID of the Access fragment.Integer203versionAM1Version of this fragment. The newerByte (8 bits)version overrides the older one as soon asit has been received.204validFromAO0 . . . 1The first moment when this fragment isIntegervalid. If not given, the validity is assumed(32 bits),to have started at some time in the past.expressed asNTP time.205validToAO0 . . . 1The last moment when this fragment isIntegervalid. If not given, the validity is assumed(32 bits),to end in an undefined time in the future.expressed asNTP time.206ServiceProtectionAO0 . . . 1If true, this indicates that this service isBooleanprotected; if false, this indicates that thisservice is free to air.
In Table 2, reference numeral 202 denotes an identifier of the access fragment, and this is an attribute for enabling a mobile terminal to uniquely identify a corresponding access fragment when it refers to the corresponding access fragment in other fragments. Reference numeral 203 denotes an attribute indicating a version of the access fragment, and enables indication of whether the mobile terminal has received an access fragment of the same version or an access fragment of a new version.
The “validFrom” attribute denoted by reference numeral 204 and “validTo” denoted by reference numeral 205 are attributes indicating a valid period of the information included in the access fragment, and “ServiceProtection” denoted by reference numeral 206 is an attribute indicating whether there is a need for a separate authentication procedure during access, as the service that can be accessed through information of the access fragment is service-protected.
TABLE 3207AccessTypeAM1Defines the type of access Possible values:Integer1.Default access object; has to exist for A/V(8 bits)streaming services (such as TV radio etc).It is used as default in case of multipleaccesses, associated SDP needed;2.Alternated access object, associated SDPneeded;3.File carousel, to be used for scheduled filedownload and file carousel type ofservices; associated SDP needed;4.File download to be used for filedownload over interaction network;associated AccessURI needed;5.Service_SMS; this type of access is usedfor creation of various SMS-based services(voting, etc); no associated SDP;6.Service_web_local; this type of access isused for pointing to locally stored webpages; no associated SDP;7.Service_web; this type of accessis used for pointing to internet services;no associated SDP;8.Service_voice_call; this type of access isused for making a phone call;9.Service_MMS; this type of access is usedfor creating various MMS-based services(voting, etc); no associated SDP; and10.Service_java_app; this type of access isused for launching Java applications.
In Table 3, “AccessType” denoted by reference numeral 207 is an attribute indicating in which method the mobile terminal capable of receiving broadcast service can receive the broadcast service that provides access information in the access fragment, and 10 Access Types are currently defined. Therefore, it is undesirably necessary to newly define Access Type every time a service of a new type occurs.
TABLE 4208AudioLanguageAO0 . . . NThe language of the Audio Stream.3-byteISO639languagecode209ExtensionURLE1O0 . . . NURL containing additional information in anAnyURIextension fragment.210ServiceIDE1M1 . . . NReference to the service fragment(s) to whichIntegerthe access fragment belongs.211UsageInfoE1O0 . . . NThis text helps the user understand whatdifference it makes to use one or the otheraccess fragment. It is mandatory in case morethan one access fragment is available at a givenpoint in time.Possibly provided in multiple languages.Attributes:Lang212LangAO0 . . . 1Language3-byteISO639languagecode
In Table 4, “AudioLanguage” denoted by reference numeral 208 is used to indicate a language of an audio stream transmitted through the access fragment, and “ExtensionURL” denoted by reference numeral 209 is used to indicate an address of an extended fragment. The “ServiceID” denoted by reference numeral 210 is an element indicating an identifier of the service that can be accessed through information of the access fragment, and “UsageInfo” denoted by reference numeral 211 is an element that provides information capable of indicating the usage and correlation of a plurality of corresponding access fragments for users when there are multiple access fragments capable of providing various access information so as to receive various types of additional services for one service, and provides an attribute “Lang” denoted by reference numeral 212 so that it can be provided in various languages.
TABLE 5213AccessURIE1O0 . . . 1The URI to the SG delivery unit(s) which contain theAnyURIsession description that the media application in theterminal uses to access the service.In case of non-broadcast service,AccessURI contains information how that particularservice can be accessed.Attribute:TypeNote; Using either AccessURI or SDP is mandatory.214TypeAM1Type of the AccessURI:Integer1 - SDP; AccessURI is a reference to SDPdescription;2 - MBMS-USD; AccessURI is a reference toMBMS user service description (MEMS-USD) asspecified in [26.346] section 5.2. It may contain oneor several SDP descriptions.215SDPE1O0 . . . 1A session description in SDP (IFTF sessionStringdescription protocol) format.(in SDPformat)216InteractiveE1O0 . . . NSpecify alternative URL of the content for retrievingAnyURIAccessURLit via the interaction channel if the content cannot bereceived via the broadcast channel.
In Table 5, “AccessURI” denoted by reference numeral 213 is an element indicating an address of the place where information on the session in which the service indicated by the access fragment is transmitted can be acquired, and has, for example, an attribute “Type” denoted by reference numeral 214. The Type 214 is an attribute indicating the type of session information and supports a Session Description Protocol (SDP) type, which is a protocol of the current IEFT, and a session information type used in Multimedia Broadcast Multicast Service (MBMS), which is portable broadcast technology specified by the asynchronous mobile communication standardization group. The “SDP” 215 is an element providing information on actual session description, and “InteractiveAccessURL” 216 is an element notifying an address so that a mobile terminal can receive the service through an interaction channel.
TABLE 6217TerminalCapabilityRequirementE1O0 . . . 1Specification of required terminalStringcapabilities, such as protocols, codecs, bitrate, and processing memory;UAprof is used for expressing thecapabilities.218BandwidthRequirementE1O0 . . . 1Specification of required networkIntegerbandwidth.A broadcast service can include multipleaccessible streams (same content) withdifferent bandwidth, so that the terminalcan make a choice depending on itscurrent reception condition.219ApplicationSpecE1O0 . . . NApplication type that can consume theStringservice using this access spec defined byMIME type.
In Table 6, “TerminalCapabilityRequirement” denoted by reference numeral 217 is an element indicating the software and hardware requirements of a mobile terminal for receiving the service that can be accessed through information of the access fragment, and based on this, a mobile terminal having a portable broadcast receiving function can determine whether it has the capability of receiving the corresponding service. In addition, “BandwidthRequirement” denoted by reference numeral 218 is an element indicating a data rate in a wireless environment of the service that can be accessed through the access fragment, and enables selection of the data rate required by the mobile terminal among several data rates, and reception of the service at the selected data rate. The “ApplicationSpec” 219 is an element providing separate information capable of receiving the service defined in MIME type.
TABLE 7220MediaInformationE1O0 . . . NOptional reference to an icon,pictogramme, animation or audio.PreviewData or reference to PreviewData isused here.Attributes:usageid221usageAM1Possible values; background, icon(e.g.).Integer(8 bits)222idAM1ID of the PreviewData fragment.Integer(8 bits)223<proprietaryE1 orO0 . . . NAny number of proprietary or application-elements/attributes>lower.specific elements or attributes that are notAdefined in this specification.
In Table 7, “MediaInformation” denoted by reference numeral 220 is an element providing preview information of the service indicated by the access fragment by the mobile terminal that received the access fragment, and has an attribute “usage” 221 and an attribute “id” 222. The attribute “usage” indicates whether it will use information of the fragment associated with the attribute “id” as preview information or background information. Reference numeral 223 denotes an element or attribute capable of providing other information that is not provided through the access fragment.
The access fragment of the conventional BCAST system, shown in Table 1 to Table 7, has the following problems.
First, because “AccessType” conceptually defines Access Type for an actual service in Table 3, Access Type should be newly defined every time a new service occurs. Second, most broadcast services provided to the mobile terminal are multimedia services requiring a high data rate, and should efficiently use radio resources in order to support high-speed transmission. Therefore, most broadcast technologies for the mobile terminal introduce the multicast concept used in the Internet Protocol, and support a method for enabling the service only in the place where the user is located. However, this method is not currently supported for the Access Type. Third, in the currently proposed broadcasting system, there is no method for simply providing to the mobile terminal a transmission scheme or transmission topology supported in the broadcasting system for access to the broadcast service.
Accordingly, a need exists for a system and method for efficiently transmitting/receiving access information of broadcast services in a broadcasting system.